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Abstract 

In a lazy functional language, the standard encoding of recursion in 
DSLs uses the host language’s recursion, so that DSL algorithms 
automatically use the host language’s least fixpoints, even though 
many domains require algorithms to produce different fixpoints. In 
particular, this is the case for DSLs implemented as Applicative 
functors (structures with a notion of pure computations and func¬ 
tion application). We propose a recursion primitive afix that models 
a recursive binder in a finally tagless HOAS encoding, but with a 
novel rank-2 type that allows us to specify and exploit the effects- 
values separation that characterises Applicative DSLs. Unlike re¬ 
lated approaches for Monads and Arrows, we model effectful re¬ 
cursion, not value recursion. 

Using generic programming techniques, we define an arity- 
generic version of the operator to model mutually recursive def¬ 
initions. We recover intuitive user syntax with a form of shallow 
syntactic sugar: an alet construct that syntactically resembles the 
let construct, which we have implemented in the GHC Haskell 
compiler. We describe a proposed axiom for the afix operator. We 
demonstrate usefulness with examples from Applicative parser 
combinators and functional reactive programming. We show how 
higher-order recursive operators like many can be encoded without 
special library support, unlike previous approaches, and we demon¬ 
strate an implementation of the left recursion removal transform. 

Categories and Subject Descriptors D.3.3 [ Language Constructs 
and Features ]: Recursion 

Keywords Applicative functors, observable recursion, HOAS 


1. Introduction 

Let us start with an embedded domain-specific language (EDSL) of 
parser rules, modelled as the GADT (see e.g. (29)) Rule. The data 
type is parameterised by the type a of parse results: 

data Rule a where 
Pure a —¥ Rule a 

Seq :: Rule (a —► 6) —► Rule a —t Rule b 
Disj :: Rule a —>• Rule a —1 Rule a 
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Fail :: Rule a 

Token :: Char —> Rule Char 

Rule provides DSL primitives Pure (match the empty string, re¬ 
turn a fixed result), Seq (sequence two rules, apply the result of the 
first to that of the second), Disj (choose between two rules), Fail 
and Token (parse and return a specified character). 

Rule uses the Applicative parser combinator style introduced and 
popularised by Swierstra et al. ED. Readers may recognise Seq 
and Pure as pure and © operators of an Applicative functor. With 
Haskell’s a ‘/‘ b for/ a b, the following bs and bs' :: Rule String 
model a language of arbitrary-length sequences of bs: 

bs = (Pure (:) ‘Seq‘ Token ’b’ ‘Seq‘ bs) ‘Disj 1 Pure "" 
bs' = ( Pure snoc ‘Seq‘ bs' ‘Seq‘ Token ’b’) ‘ Disj 1 Pure "" 

According to rule bs , matches either start with token ’ b ’, followed 
by another match of bs or they are empty. The rule Pure (:) has 
no parse behaviour of bs, but produces the list cons operator (:) 
as a result, so that the parsed token ’b’ is consed with the result 
of the recursive match. For an empty match, the empty string " " 
is returned. Parser rule bs' defines the same language and parse 
results but expects the recursive match first, and the token ’b’ 
second, bs' is left-recursive : it refers to itself in a left-most position. 

The algorithm nullable :: Rule a —J Bool checks if a rule accepts 
the empty string: 

nullable (Pure _) = True 

nullable (Seq a b) = nullable a A nullable b 

nullable ( Disj a b) = nullable a V nullable b 

nullable Fail = False 

nullable (Token _) = False 

This definition is satisfactory for finite rules, but a problem arises 
for infinite, recursive production rules like bs and bs' above. 

A known problem of parser DSLs like Rule is that left-recursive 
rules are not treated well. Unlike nullable bs (which is True), 
nullable bs' is _L: computation loops forever. Computationally, 
nullable bs' loops when considering the left-most part of its first 
alternative. Denotationally, nullable bs' corresponds to the fix- 
point of a certain function, and the least fixpoint _L we get from 
Haskell is not the one we would like. 

This example shows that for DSLs like our grammar model, algo¬ 
rithms need more control of how fixpoints are calculated. As such, 
it is inappropriate to rely on Haskell’s least fixpoints. Otherwise, 
parsing libraries are restricted to top-down parsing algorithms, left- 
recursion is difficult (although some algorithms deal with it any¬ 
way, e.g. fl6l ) and some algorithms are impossible (e.g. print a 
representation of a rule’s parsing structure). Also for DSLs with re- 
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cursion in other domains, useful analyses and transformations are 
rendered impossible by the implicit or unobservable recursion. 

1.1 Overview and Contributions 

Like Oliveira and Cook (25), we propose to represent recursive 
definitions using a recursive binder p, e.g.: 

bs = p s. (Pure (:) ‘Seq‘ Token ’b’ ‘Seq‘ s ) ‘Disj‘ Pure "" 
After some more background in section[2] we encode such a prim¬ 
itive in HOAS style in section[3] We don’t use standard HOAS as 
it allows certain illegal terms, but use Carette et al.’s finally tagless 
style instead. We adapt the technique from lambda terms to applica¬ 
tive DSLs (no Lambda binder but a pure primitive instead) with a 
new representation of the recursive binder: the afix primitive, 
class Applicative p =>■ ApplicativeFix p where 

afix :: (V q. Applicative q =4- p (q a) —>• p (q a)) —>• p a 

The primitive differs from Carette et al.’s Lambda because of 
its rank-2 type. We show how it models a separation between 
values and effects of the DSL. This reflects the separation that 
distinguishes applicative DSLs from monadic ones and makes them 
suited for analysis and optimisation. In section [4] we discuss an 
axiom that governs the intended semantics (recursion) of afix. 

A downside of an explicit fixpoint primitive like afix is that we lose 
some of the elegance of Haskell’s standard recursive equations. In 
section [5] we define a shallow form of syntactic sugar to recover 
Haskell’s standard elegance in the form of the alefQconstruct, e.g.: 

alet bs = (:) ® token ’b’ © bs ® pure "" 

We define scoping and typing rules for alet and a desugaring into 
standard Haskell, all implemented in our branch of the Glasgow 
Haskell Compiler (GHC). Using generic programming techniques, 
we implement a mutual recursion primitive that reduces mutually 
recursive bindings to a series of recursive bindings. 

Finally, in section [6] we demonstrate the usefulness of our tech¬ 
niques with two larger examples. One example concerns a simple 
functional reactive programming (FRP) model of electronic hard¬ 
ware and the second example shows a non-trivial parser transfor¬ 
mation that removes left-recursion from a parser. 

2. Background, examples and machinery 

2.1 More fixpoints 

Consider how cbe' = nullable bs' produces _L as the wrong 
solution of a recursive equation. Denotationally (see e.g. l36l ). 
cbe' = _L is the least fixpoint of cbe}' under the standard complete 
partial order on valuesjj 

cbefi s = (s A False) V True 

The fact that this least fixpoint is _L is especially unfortunate be¬ 
cause chef does have anon-_L fixpoint: cbef True = True. 

Based on nullable, we can also calculate the first set of a rule: the 
set of characters that can start a successful parse. 
firstSet :: Rule a -A Set Char 
firstSet (Pure _) = Set.empty 

'The word “applet” was already taken... 

2 Note: this is not the standard meaning of cbe' but it can be shown 
because of the structure of nullable and bs 1 . 


firstSet (Seq a b) = 

if nullable a then firstSet a U firstSet b else firstSet a 
firstSet (Disj a b) = firstSet a U firstSet b 
firstSet Fail = Set.empty 
firstSet (Token t) = singleton t 
If nullable bs' were True instead of _L, then /s' = firstSet bs' 
also gives us the least fixpoint of a function fsf 
fsf s = (s U singleton ’b’) U Set.empty 
fsf has several fixpoints: singleton ’b’, but also _L (chosen by 
Haskell) and Set.fromList "abc". Only one corresponds to intu¬ 
ition and language theory: singleton ’b ’. To conclude, algorithm 
authors should use domain knowledge to choose appropriate fix- 
points and the representation of recursion should support this. 

2.2 Applicative Functors 

Rule’s constructors fit the pattern of an Applicative functor (23], a 
type class modelling structures with a notion of pure computations 
(pure) and application (©)0 

class Functor p => Applicative p where 
pure :: a-i p a 

(©) :: p (a b) p a —> p b 
instance Applicative Rule where 
pure = Pure 
(©) = Seq 

Rule also instantiates Alternative: a class of Applicative functors 
with a notion of disjunction (®) and failure (empty). 
class Applicative p =4- Alternative p where 
(®) :: p a —t p a p a 

empty :: p a 

instance Alternative Rule where • • • 

2.3 Applicative functors vs. Monads 

The reason we work with Applicative DSLs and not for example 
the better known Monads is that for an analysis to handle recursive 
equations (our main goal), it must be able to observe the structure 
of the recursive equation. Monadic DSLs use a monadic bind 
typed m a —> (a —> m b) —t m b that allows the effects structure 
of a term to depend on the result value of a previous term, rendering 
the computation impossible to analyse. Consider the term 
evilMonadic = donf- evilMonadic 

if n = 100 then evilMonadic 
else return (100 — n) 

It is unclear if this recursive equation has a non-_L solution, but 
even if it has, it is hopeless to find it. The do-notation translates 
to evilMonadic >= (An —»• if n & 100 ■ • •) and this second 
argument is a function that may return entirely different rules for 
different n. The monadic bind can not inspect all cases, so that 
finding non-least fixpoints is hopeless in all but the simplest cases. 

Unlike ~^=, the Applicative apply operator ®’s type (p (a -A 
b) -A p a —»• p b) prevents computations’ values from influ¬ 
encing the structure of subsequent computations. This separates 
a computation’s effects from its values, corresponding for parsers 
to context-free-ness (roughly, see (2p ). This makes Applicative 
parser libraries well-suited for analysis and optimisation (H[3TJ and 
makes the goal of finding non-least fixpoints feasible. 


3 We consistently omit Functor instances because its fmap or ® 
method should satisfy/ <D p = pure f © p. 




2.4 Composing Applicative functors 

An important tool for us is the composition of two Applicative 
functors p and q l23l . The composed functor (p o q) is again 
Applicative. 

newtype (p o q) a = Comp {comp :: p (q a)} 
instance ( Applicative p, Applicative q) =>■ 

Applicative (p o q) where 
pure = Comp ■ pure ■ pure 
f © v = Comp $ (©) ® comp f © comp v 

For a composed functor (poq), we call p and q the outer resp. inner 
functor. Terms in either functor can be lifted to (poq). Also useful 
is a function withlnner, lifting operations on the inner functor q: 
liftOuter :: (Functor p, Applicative q) =>■ p a —>• (p o q) a 
liftlnner :: Applicative p=$-qa^t (poq) a 
withlnner :: Functor p =$■ (q a —¥ h a) —¥ 

(p o q) a -> (p o h) a 

2.5 Effectful recursion, not value recursion 

We study DSL terms defined as the solution of recursive equations, 
like the examples bs and bs'. This is a different kind of recursion 
than the value recursion studied by Erkok and Launchbury IT4i . 
They study monads that support recursive values in the param¬ 
eters and results of effectful computations. For example, GHC’s 
Data.IORef (a mutable references interface in the 10 Monad) 
supports the cells’ values to be defined lazily. Using the recursive 
do syntax of GHC’s DoRec extension (evolved from the original 
proposal), a function can create mutually recursive reference cells: 
data Node = Node Int (IORef Node) 
mk2nodes = do rec p <— newIORef (Node 0 r) 
r *— newIORef (Node 1 p) 
return p 

Value recursion is only interesting in the context of monadic com¬ 
putations. For Applicative functors, the separation of values and 
effects limits the value recursion entirely to the value level. The 
same effect can then be achieved by using the standard fix at the 
value level (see section [4~2| . It is the monadic interplay of effects 
and values that makes value recursion interesting. In this paper, we 
study effectful recursion, a different form of recursion that is more 
naturally associated with applicative functors. Effectful recursion 
is used to define effectful recursive DSL terms, like bs and bs'. 

3. A recursion primitive 

Let us define our recursion primitive afix. We start from more naive 
definitions and iteratively adapt it to satisfy our requirements. 

In our Applicative Rule DSL, we might represent a recursive 
binder in a naive HOAS style with a new Rule primitive FixO: 
FixO :: ( Rule a Rule a) —> Rule a 
bs = FixO $ Xbso —► (:) ® Token ’b’ © bso CD pure "" 
bs 1 = FixO $ Abs' 0 —> snoc ® bs' 0 © Token ’b’ ® pure "" 

Unfortunately, this representation allows meaningless definitions: 
badBind = FixO $ A self —> case self of Pure _ —>• self 

—¥ Pure 0 

badBind treats its recursive parameter non-parametrically and does 
not model a usage of the recursive binder p. Such definitions are 


not excluded by FixO’s type. Chlipala explains how this compli¬ 
cates DSL algorithms like nullable, requiring an inverse algorithm 
mapping result values (here: booleans) back to DSL terms (6). 

We use Carette et al.’s finally tagless style (5) to solve this. Chli- 
pala’s alternative Parametric HOAS j6| is discussed in section[7] 

3.1 Finally tagless style (second attempt) 

In Carette et al.’s finally tagless style, a parser rule with result type 
a is not a value of data type Rule a, but of type FinalRuleO a: 
class Applicative p =? CharParser p where 
token :: Char —> p Char 
type FinalRuleO a = 

V p. (Alternative p, CharParser p) => p a 
Under this definition, a rule is something that can be interpreted in 
any functor that supports the required primitives, e.g. bs and bs': 
bs, bs':: FinalRuleO String 
bs = (:) ® token ’b’ © bs ® pure "" 
bs' = snoc ® bs' © token ’b’ ® pure "" 

The quantification over p in FinalRuleO rules out definitions like 
badBind. Since a term in the DSL has to support any functor p, it 
has no way of inspecting recursive references of type p a. 

Writing algorithms in this final style is reminiscent of program¬ 
ming with Church encodings of data types. The polymorphism of 
FinalRuleO is used by instantiating p with a special-purpose in¬ 
terpretation functor carrying intermediate analysis results. In the 
instances of Alternative and CharParser for this functor, pars¬ 
ing primitives like pure, ® and token are handled. The analysis 
function nullableF just unwraps the result from the functor: 
newtype Nullablelnterp a = NullI Bool 
instance Applicative Nullablelnterp where 
pure _ = NullI True 

(NullI a) © (NullI b) = NullI (a A 6) 
instance Alternative Nullablelnterp where • • • 
instance CharParser Nullablelnterp where • • • 
nullableF :: FinalRuleO a —¥ Bool 
nullableF (NullI r) = r 


3.2 Finally Recursive (third attempt) 

So how can we add a recursive binder to such a final DSL? The 
obvious solution mimics Carette et al.’s lambda construct: 
class ApplicativeFix 0 p where afix 0 :: (p a —>• p a) —¥ p a 
bs = afix 0 $ Xbso —> (:) © token ’b’ © bso (Dpure "" 
bs' = afix 0 $ Xbs' 0 —y snoc © bs' 0 © token ’b’ ® pure "" 

We can extend our nullableF analysis to support afix 0 : 
instance ApplicativeFix 0 Nullablelnterp where 
afix 0 pf = pf (NullI False) 

This instance passes NullI False to pf, specifying that recursive 
occurrences are assumed not to accept the empty string. 

3.3 Applicative problems 

Unfortunately, a problem with afix 0 remains in complex transfor- 
mation s like the left-recursion removal transform to be described in 
section [®2] It will transform for example the left-recursive rule bs' 
into an equivalent, non-left-recursive rule: 
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transformPaull bs' = foldr ($) ® bsHead' © many bsTail' 
where bsHead' = pure " " 

bsTail' = (:) ® token ’b’ 

More details follow, but essentially bs' is split in two parts: 
bsHead' is what remains of the rule with leading self-references 
removed and bsTail 1 contains the parts of the rule that follow lead¬ 
ing self-references. The transformed rule parses bsHead 1 first and 
then iteratively parses bsTail' using many :: p a -A p [a]. The 
initial result of bsHead' has type String, and the parse results of 
bsTail', typed String —¥ String, are iteratively applied to it using 
foldr ($), to obtain the same parse results as before. 

Actually performing this translation presents several challenges. 
For a rule like bs 1 of the form afix 0 bsf, we have to derive rules 
bsHead' and bsTail' from bsf'. Distinguishing leading from non¬ 
leading recursive references is a first problem, but let us assume for 
now they are all leading (like in bs'). It is then easy enough to find 
bsHead' as bsf empty. Deriving bsTail' from bsf is harder. 

To derive bsTail' (of type p ( String -¥ String )) from bsf' (of 
type p String —>■ p String), we can try to somehow turn bsf into 
a value of type p (String — > String) —> p (String —> String), 
i.e. make all rules produce a value that can depend on the String 
result of a previous match. The rules in bsf" ignore this value, but 
we can now apply bsf" to pure id, i.e. instantiate leading self¬ 
references to a pure parser returning the previous parse result. 

Generalising slightly, what we crucially need is a coapplicative 
operator coappO (note the symmetry with the type of ©): 

coappO :: (p a —>• p b) —> p (a —»• b) 
coappO should satisfy pf (pure v) = ($p) ® coappO pf for 
pf :: p a p b and v :: a. However, it cannot be implemented 

We might say that the polymorphism of FinalRuleO has to be 
instantiated too early. If we could instantiate p to (p o ((—>) a) Q 
then we could lift the Applicative and related instances to this 
composed functor, lift pure id to type (p o ((—>) a)) a and call 
pf with this value to obtain a value of (p o ((—>■) a)) b which is 
essentially p (a —»• b). However, even though we can instantiate a 
FinalRuleO’ s p parameter as we like, ( p o ((—>) a)) is not suited 
as the type a becomes known only during the analysis of a term. 

We note that coappO’ s type is precisely that of Carette et al.’s 
Lambda constructor. So why can’t we simply add a lambda con¬ 
structor to our applicative DSL to solve our problem? Unfortu¬ 
nately, such a constructor is a bad idea for many DSLs, includ¬ 
ing our parsing example. Even for a simple recursive descent (RD) 
parse algorithm, this lambda operator cannot be handled: 

lambdaRD :: ((String —y [(String, a)]) —> 

String —> [(String, a)]) —»• String —»• [(String, a —»• 6)] 
lambdaRD pf s = ? 


3.4 Rank-2 types to the rescue (our final proposal) 

The solution we propose is to change the type signature of afix 0 : 
class Applicative p =>■ ApplicativeFix p where 
afix :: (V q. Applicative q #- 

(po q) a ->• (po q) a) -4 p a 

afix ’s type requires that the value of the recursive variable of afix’a 
argument can be wrapped in an arbitrary Applicative functor q 

4 We ignore unsafe techniques like dynamic typing and partiality. 

5 (—>) is Haskell’s curried arrow type constructor: (—>) a b = a —»• b. 


with the recursive definition’s result value coming out in the same 
functor at the end. 

This restriction is strong enough for the definition of coapp. We 
can instantiate the type constructor argument q to the environment 
functor ((—>-) a), and exploit its standard Applicative instance: 
coapp :: Applicative p =>• (V q . Applicative q =>- 
(po?)o^(po q) b)^-p(a^-b) 
coapp p = comp $ p $ liftlnner id 

Our experience shows that afix’ s type is not too restrictive though: 
Applicative- style primitives on a functor p can be lifted to (po q) a 
for any Applicative q, e.g. Alternative and CharParser jj 
instance (Alternative p, Applicative q) => 

Alternative (p o q) where 
empty = Comp empty 
va CD vb — Comp (comp va ® comp vb) 
instance (CharParser p, Applicative q) => 

CharParser (p o q) where 
token = liftOuter ■ token 

We can adapt the previous examples bs and bs' as follows, 
type FinalRule a = V p. 

(Alternative p, ApplicativeFix p, CharParser p) => p a 
bs, bs':: FinalRule String 

bs = afix $ As —»• (:) ® token ’b ’ © s ® pure "" 
bs' = afix $ As —>■ snoc ® s © token ’b ’ ® pure "" 

The additional power of afix over afix 0 is not always needed. 
In such cases (like our nullable), the quantified functor q can be 
instantiated to Identity. 

runldComp :: Functor p => (p o Identity) a —¥ p a 
runldComp p = runldentity ® comp p 
wrapIdComp :: Applicative p => (V q . Applicative q => 
(P° q) « (P° ?) a) ->• p a -b p a 

wrapIdComp f s = runldComp $ / $ liftOuter s 
instance ApplicativeFix Nullablelnterp where 
afix pf = wrapIdComp pf (NullI False) 

With firstSet similarly adapted, the results for bs are unchanged: 
nullableF bs = True, firstSetF bs = singleton ’b’, but 
left-recursion is now supported: nullableF bs' = True and 
firstSetF bs' = singleton J b\ 

3.5 The meaning of afix’s type 

Let us try and gain more insight into the meaning of afix’s type: 
afix :: V p. ApplicativeFix p =£- 
(V q. Applicative q =$> p (q a) p (q a)) p a 
A useful tool is Reynolds’ notion of parametricity (32][34). Because 
we just want to gain insight, we freely use imprecise formulations 
and ignore intricacies like strictness QO, although we do believe the 
results could be made more exact if necessary. 

Let us consider the type of afix’s arguments: 

V q. Applicative q => (p o q) a -»• (p o q) a 
We conjecture that the following free theorem holds for values pf 
of this type: 


6 This instance of Alternative (poq) arbitrarily lifts p’s Alternative 
instance and not q’s, but in our case, q’s special role warrants this. 
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Theorem 3.1. For all qi, q? Applicative, for k : q\ a q? a 
respecting the Applicative operations and u :: (p o ql) a, 
withlnner k (pf u) = pf (withlnner k u). 

This theorem states that for any k, applying withlnner k before or 
after pf has the same effect. Consider the constant functor K : 
data K a = K 

instance Applicative K where { pure _ = K: _ = K\ 

With k — A„ -4 K, withlnner k maps values of (p o q) a 
to (p o K) a, ef fectively erasing the value of the computation in 
p. Theorem |3.1| then implies that applying pf to an argument u 
and erasing the value of the result is equivalent to first erasing m’s 
value and then applying pf to it. This means that the above theorem 
states a familiar property, namely that afix’ s arguments pf respect 
the separation between values and effects of applicative functors. 

4. An ApplicativeFix Axiom 

With the key points of our approach established, let us consider the 
properties a reasonable implementation of ApplicativeFix should 
satisfy. Many Haskell type classes are associated with such axioms 
that can sometimes even be linked to category theory or mathemat¬ 
ics in general. We have not identified such a relation, but we do 
propose an axiom that should hold for a fix. 

4.1 Fixpoint law 

The ApplicativeFix fixpoint law states that an implementation of 
afix should always deliver a fixpoint: 

afix pf = wrapIdComp pf $ afix pf 
Remember that denotationally, Haskell recursive definitions pro¬ 
duce the least fixpoint of a function pf (36). This law states that 
afix must also return a fixpoint, but not necessarily the least. Note 
by the way that it also implies a behaviour on constant functions: 
Corollary 4.1 (Constant preservation). If x is not free in g, 
afix (Ax —> liftOuter g) = g. 

4.2 Interesting non-axioms 

There are two axioms that we want to explicitly not propose. We 
discuss them, nevertheless, as they shed more light on the meaning 
of our afix primitive. 

Left shrinking considered harmful The first such property is 
an analogon of Erkok and Launchbury’s Left Shrinking law for 
MonadFix fT4l or the equivalent for Paterson’s ArrowLoop (27). 
For ApplicativeFix, one might expect the following left shrinking: 

afix (Ax -4 liftOuter a® f x) = a © afix f 
with x not free in a and a :: p (v —>■ v) for some p and v. 

Let us consider what this proposed axiom would mean for an 
example parser for an infinite number of as, defined as follows: 

as = afix $ As —> (:) ® token ’a ’ ® s 
Under the left-shrinking assumption, the above is equivalent to a 
single token parser followed by an infinite effect-free parser: 
as = afix $ A as' -4 (:) ® token ’a’ © as' 

= (:) ® token ’a’ © afix $ A as' -4 as' 


However, this new expression is not at all equivalent to the original. 
The left shrinking property states that computations not depending 
on recursive occurrences can be lifted out of the recursive equation, 
their effects no longer taking part in the recursion. As such, the ax¬ 
iom is defining for the value recursion that Erkok and Launchbury 
model and rules out the effectful recursion we aim for. 

Fixing what is pure? A second property that not all reasonable 
instances of ApplicativeFix satisfy, prescribes a form of fixpoints 
for recursive definitions that do not add effects: 


afix (fmap h) = pure (fix h ) 

for any h typed a -4 a. The right hand side is a fixpoint of fmap h, 
but not necessarily the one we want. In an Alternative functor 
p, empty is also a fixpoint and it is in fact the natural one for 
most examples in this text. For instance, in a parser DSL, the left- 
hand side models a non-terminal X with a single production rule 
X -¥ X, equivalent in language theory to an empty rule. 


5. Making afix practical 

We turn our attention to some tools that make it practical to imple¬ 
ment and work with DSLs using afix. 

5.1 Some Tools 

First, unlike alternative solutions (2) [TT), afix supports higher- 
order combinators without primitive support. These are observably 
recursive analogues of the standard many and some combinators: 

manyAF, someAF :: (Alternative p , ApplicativeFix p) => 
pa^p[a] 
someAF f = (:) © / © manyAF f 
manyAF f = afix $ As -4 (:) ® liftOuter f © s ® pure [] 

Note that manyAF and someAF’ s types only differ from their 
standard analogues in the ApplicativeFix constraint. 

A standard function afixlnf implements afix by going back to 
Haskell’s unobservable recursion. This sometimes makes sense, for 
example when interfacing with existing libraries that are designed 
to work with Haskell’s implicit recursion. We show an instance for 
uu-parsinglib’s parser representation. Also useful is afixKill, 
which replaces recursive occurrences with a failing empty rule. 

afixlnf :: Applicative p =£- (V q . Applicative q => 

(P° q) a -4 (po q) a) -4 p a 
afixlnf f = fix $ wrapIdComp f 

instance ApplicativeFix (P st) where afix = afixlnf 
afixKill :: Alternative p => (V q . Applicative q => 

{po q) a -4 (jpo q) a) -4 p a 
afixKill f = runldComp $ f empty 


5.2 Arity-Genericity 

With afix modelling effectful recursion on one variable, the next 
question is what to do about mutual recursion. Instantiating afix 
at type (V b. ApplicativeFix b =>• (/ o 6) (al, a2) -4 (/ o 
b) (al, a2)) -4 f (al, a2) is not a solution because the type 
/ (al, a2) does not allow both recurrands to produce different 
effects. What we would like is a primitive of the following type: 
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assocComp 1 :: Applicative p => 

{{poql)oq2)a-+{po{qloq2))a 
assocComp 2 ■■ Applicative p => 

(P o (ql o qg)) a ->■ ((po ql) o qg) a 
liftComposed :: (Applicative p, Applicative q2) =$■ 
(poql) a -+(po(q2o ql)) a 


Figure 1 . Utility functions for working with functors (p o q) (im¬ 
plementations omitted). 


afix 2 :: ApplicativeFix p =D- (V q . Applicative q =4- 
((P ° q) ai -f (P ° ?) 02 -f (p o q) ai, 

(P o ?) or ^ (p o g) 02 —f (p o g) o 2 )) ->• (p 01, p 02) 

This is not an instance of afix’s type, but we can construct such 
a primitive from it, taking inspiration from Bekic’s theorem (36). 
This theorem relates mutually recursive bindings to repeated appli¬ 
cations of the fix operator. We imitate the form for afix, exploiting 
the polymorphism of afix 2 ’s argument and juggling the (• o •) type 
constructor in the types (using utility functions from Figure [TJ. 

afix 2 pf = (fp 1 ,fp 2 ) where 
fp 1 = afix $ A/p'j —>• 

let fp 2 = Comp $ afix $ Xjp 2 —> comp $ 

assocComp 2 $ snd pf (liftComposed fp j) 
( assocComp 1 $ Comp fp 2 ) 
in fst pf fp[ fp 2 
fp 2 = ... (analogous) 

This definition is obscured by technicalities. In the first call to afix, 
the recursive argument fp[ is of type (po ql) a\ for an arbitrary ql. 
However, in the second call to afix, fp 2 is of type (p o qg) ( ql a 2 ) 
for an arbitrary q2. The trick is then to apply pf with its type 
parameter q instantiated to (q2 o ql) and exploit associativity of 
the (• o •) type constructor to fit everything together. 

Now, we can do this for any arity, but this is not very effective: we 
can only hope to implement a finite number of afix and addition¬ 
ally, the size of the definition of afix t increases exponentially with 
i. Luckily, GHC’s type system allows us to do better. 

Omitting details for spac e reasons, we have used techniques de¬ 
scribed by McBride l22ljto develop an arity-generic or polyvari- 
adic version of afix. With encoding artefacts removed and using 
ellipses in a not fully formal notation for type lists, this is its type: 

nafix :: V (p :: * —> *) ([ti • • • t n \ :: [*]). ApplicativeFix p =>■ 
((Vg : * -¥ *. Applicative q => 

(p o q) ti -f (p ° q) t n -A- (p o q) ti ), • • • , 

(Vg : * —t *.Applicative q => 

(p O g) ti -¥ -» (p O g) f n -> (p o g) t n )) -¥ 

(pti, . . . ,pt„) 

This arity-generic version of afix gives us effectful mutual recur¬ 
sion at any arity without primitives beyond afix. The implementa¬ 
tion of nafix can be found in our GHC branch (see Section [5~4] i. 

5.3 Syntactic sugar 

By writing recursive definitions in terms of this new fixpoint prim¬ 
itive, we lose some of the elegance of Haskell’s standard let bind¬ 
ings. But because our ApplicativeFix and afix are a general tool 


7 We use type families instead of multi-parameter type classes though. 


<3; T b p : * —»• * Q IF ApplicativeFix p q fresh 
Vi = l..n, Q A Applicative g; 

F, g : * -A *, {Xj : (p o g) tj} j=1 „ F e t : (p o g) 1 1 
Q; T, {xi-. P U} i= ^ n he-.T _ 

Q ; T, F alet { Xi = ei } i=1 n in e : T 

(T-ALet) 

Figure 2. Typing alet bindings 


for Applicative functors requiring observable effectful recursion, a 
shorthand notation to recover this elegance makes sense. Since we 
work in an applicative style, a syntax that resembles standard let 
bindings is natural: we propose the alet-notation: 

alet bs = pure "" ® (:) ® token ’b’ © bs 
Note the use of a top-level alet. We allow mutual recursion, like in 
the following simple expression parse^J 

alet expr = (+) ® expr © token ’ + ’ © factor 
® factor 

factor = (*) ® factor ® token ’ * ’ © term 
® term 

term = token ’ (’ 3D expr d token ’) ’ 
ffi decimal 

Syntactic and scoping rules for alet are analogous to normal let 
bindings. Its typing rule is presented in Figure [2] using notation 
from Vytiniotis et al. |[33l . Specifically, their typing judgement 
Q ; r F e : r, where Q is a set of constraints, F is a typing 
environment, e an expression and r a type. We write some kind 
annotations, typing context entries for type variables and explicit 
type applications of polymorphic values for clarity. The typing rule 
for alet is not standard, but it reflects the requirements of our afix 
and nafix primitives: the definitions of bound variables Xi are type- 
checked against type (p o b) k where 6 is a fresh Applicative 
functor, and all x :i are bound at type (p o b) /,,. The body of the 
alet construct is type-checked with all Xi bound at type p ti. 

With this typing rule. Figure [3] defines a type- and syntax-directed 
desugaring A, transforming alet to regular Haskell. Essentially, 
all recursively bound variables Xi are converted into open recursive 
functions x\. We generate a call to the n-ary nafix primitive and 
project out x t from the resulting n-ary tuple. Finally, we replace 
occurrences of Xi in the body with x,. Type soundness of the 
translation follows easily from type checking the right-hand side 
of the translation B against the type of the original alet construct. 
Theorem 5.1 (A is type-preserving). 

Q;rFe:T^Q;rFA{r)(e):T. 

We don’t formalise top-level alet.s, a declaration form of alets. 

5.4 Implementation 

We have extended GHC to parse, type-check and desugar alet ex¬ 
pressions. We perform the translation in Fig.[3]during the desugar¬ 
ing phase, which translates scope- and type-checked Haskell code 
into GHC’s explicitly typed core language (a variant of System F u 
extended with features like equality coercions (30l ). We currently 
support alet expressions as defined in this text. Still missing is 
support for top-level alets and type signatures for alet bindings 


8 Note: we use shorthands ® and ED that behave like © but ignore the 
result of their second resp. first argument, e.g. v <=E w — const ® v ® w. 
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A(Q\ T) (alet {a;* = ei} tol n in e) 
A(Q\ T> (e) 


B({ti} i= i,.„) ( alet {m = in e) 

( Q; f 1 1- p : * —► *, Q l)r ApplicativeFix p 

W1 | V* Q A Applicative 6; T, &:*—>■ *, fxy : (poi>) t,}^ t n h ej : (p o 6) tj 
(compositionally apply _A{Q; T) on components of e) 


«<{*}«=!..„> (alet {x* = ej} i _ 1 n in e) 


/ = nafix S[ti,J4 ^x}, • • • , 

{Xi = 7Ti@[(p fi) • • • (p t n )] /} i=1 n 
in [xi/xi] i=1 „e 


Figure 3. The type-directed translation of alet bindings. We write some explicit type applications for clarity. 



Figure 4. An SR-latch, using a pair of cross-coupled NOR gates. 


(but type annotations in the bodies can be used instead). The exam¬ 
ples in this text without top-level alets are supported. The code is 
available on GitHub with instructions for buildin^jand pointers for 
trying out examples and navigating the code. 


6. Examples 

6.1 Functional Reactive Programming 

A domain where our techniques are useful is functional reactive 
programming (FRP), a declarative programming model that de¬ 
scribes a system in terms of time-varying functions instead of mu¬ 
table state with applications in robotics (28), animation G3)and 
graphical user interfaces Q9). 

A simple FRP model may consider behaviours as functions of time, 
making them an instance of the environment functor l23l : 
type Behaviour = (—t) Time 
instance Applicative ((—t) a) where 
pure = const 
f ® g = At -4 / t (g t) 

FRP provides a form of state through the delaying of behaviours. 
For discrete time models, the behaviour delay v bhv produces 
value v first and the delayed values of bhv next. We assume func¬ 
tions prevT :: Time —»• Time and initT :: Time. 
class Applicative f => Delayable f where 
delay :: a —>• f a —»• / a 
instance Delayable Behaviour where 

delay v b = Xt — i if t = initT then v else b $ prevT t 


6.1.1 Modelling electronic circuits with flip-flops 

Let us use FRP to model event networks and, in particular, elec¬ 
tronic circuits. Figure [4] shows an SR-latch, a simple flip-flop cir- 

: http://github.com/ilyasergey/GHC-XAppFix/wiki 


nor x y = -< (x V y) 

srLatch :: Delayable f => f (Bool, Bool) —y f (Bool, Bool) 
srLatch inputs = let qi = nor ® r © delay False qi' 
qi' = nor ® s © delay False qi 
in (,) ® qi® qi' 
where r = fst ® inputs 
s = snd © inputs 


Figure 5. An FRP implementation of an SR latch’s without alet. 

cuit with two stable states, sometimes used to store information. 
The circuit has two input wires: R and S, and two output wires: 
Q and Q (opposite in correct states). If S and R are high, they set 
resp. reset the state of the circuit (the value of Q). 

Figure [5] shows an FRP model of the SR-latch over an arbitrary 
Applicative functor with a Delayable instance, reacting to events 
of type (Bool, Bool) (the values applied to the input wires). The 
latch’s recursion is modelled in the standard way, and there is no 
problem to simulate the circuit: 

samplelnput = delay (True, False) $ const (False, False) 
The simulation shows that our sample input correctly initialised 
the circuit: map (srLatch samplelnput) [initT..] gives us 
[(False, True), (False, True ),...]. 

6.1.2 Delayable applicative functors 

In Figurep] the recursive calls to qi and qi are guarded by delays, 
essential for the proper functioning of the example. If we remove 
the delays, our example no longer terminates. For more complex 
examples, such errors can be less obvious and lead to bugs. 

Our approach can already do better. If we model the recursion 
using ApplicativeFix, we can scan for erroneous loops upfront 
and report errors early on. We just need to lift the Delayable class 
to composed functors (omitted) and change srLatch to use alet. 
We use liftOuter to lift a and b into the composed functor: 
srLatch2 :: (ApplicativeFix f, Delayable f) =$■ 
f (Bool, Bool) —> f (Bool, Bool) 
srLatch2 inputs = 

alet qi = nor ® liftOuter r © delay False qi' 
qi' = nor ® liftOuter s © delay False qi 
in (,) ® qi © qi' 

where ... — see Figure [5] 

In a final style, we can analyse this definition with a custom functor: 
TestValid a ignores its parameter a, but keeps track of the valid- 
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ity of a circuit and its current minimum delay. The Applicative and 
Delayable instances initialise and combine the validity and mini¬ 
mum delay values in the obvious way. 

data Validlnterp a = VI {isValid :: Bool, viDelay :: Int} 
instance Applicative Validlnterp where 
pure _ —VI True 0 

VI va da © VI vb db = VI (va A vb) (min da db) 
instance Delayable Validlnterp where 
delay _ (VI s d) = VI s (d + 1) 

In the ApplicativeFix instance, we test if the recursive function 
properly introduces a delay: we pass it a recursive occurrence with 
a delay of —1. If what comes back doesn’t have an increased delay, 
the circuit is invalid: 

instance ApplicativeFix Validlnterp where 
afix f = case wrapIdComp f $ VI True (—1) of 
VI t d | d < 0 VI False d 

VI t d j otherwise —► VI t d 

Reassuringly, isValid (srLatchS (VI True 0)) is True. 

6.2 Left-recursion removal 

The largest example in this paper is the previously mentioned algo¬ 
rithm that transforms left-recursive parsers into an equivalent non¬ 
left-recursive form. It is inspired by a previous implementation of 
a uniform version of the Pauli transformation fi~7l p. 304] in the 
grammar-combinators library CD. This is a complex transfor¬ 
mation and we think it shows other transformations like the ones 
needed for parsing with derivatives (24l are possible as well. 

In section [33] we discussed how transformPaull transforms the 
example left-recursive rule bs' into a non-left-recursive equivalent: 
transformPaull bs 'S 

foldr ($) ® bsHead' © many bsTail' where 
bsHead' = pure " " 
bsTail' = (:) ® token ’b’ 

The core of the transformation is in the implementation of afix, 
where we transform a parser like bs' = afix bsf' to the above. The 
difficult part is deriving bsHead' and bsTail' from pf and we have 
already discussed some of the techniques for doing this in section[3] 
To derive the first, we pass pf a recursive occurrence that behaves 
differently in different positions: it always fails in a head position 
and behaves as an actual recursive occurrence in tail positions. In 
a similar but more complicated way, we construct bsTail' , but not 
without the coapp function from section [3~4| 

We model different positions for a parsing rule as three contexts: 
PurePos (a position where a parser must not consume any input), 
HeadPos (the left-most position of a non-terminal definition where 
a parser must consume input) and TailPos (a position where input 
has already been consumed). The HeadPos context can addition¬ 
ally specify that primitive parsers in this position are to be either 
killed (replaced with empty ) or left unmodified: 
data RuleCtx = PurePos 

| HeadPos HeadMod 
| TailPos deriving Eq 

data HeadMod = KillHeads \ DontTouch deriving Eq 
modHead :: Alternative p => HeadMod —>• p a —»• p a 
modHead KillHeads _ = empty 
modHead DontTouch p = p 


For an underlying parser functor p, we define a type of trans¬ 
formable parsers that support these three contexts. This type of 
transformable rules plays the role of the interpretation functor 
that we instantiate the polymorphism of the rules with. We define 
the algorithm by providing instances for the relevant type classes 
Applicative, Alternative, CharParser and ApplicativeFix. 

data PaullT p a = PaullT {paullT :: RuleCtx —>• p a} 
The Alternative instance just lifts p’s operations in all contexts: 
instance Alternative p => Alternative (PaullT p) where 
empty = PaullT $ const empty 

a ® b = PaullT $ A ctx —>• paullT a ctx ® paullT b ctx 

In the Applicative instance, we define the behaviour of the parsers 
in the three contexts. The rule for sequencing is the most complex, 
because care has to be taken to correctly define how the two se¬ 
quenced parts can each be in the left-most position of a rule: 
instance (Alternative p, Applicative p) =>■ 

Applicative (PaullT p) where 
pure v = PaullT r where r PurePos = pure v 
r (HeadPos _) = empty 
r TailPos 3m pure v 

rf © rv = PaullT r 
where r ctx@(HeadPos « 

paullT rf PurePos © paullT rv ctx 
® paullT rf ctx © paullT rv TailPos 
r ctx = paullT rf ctx © paullT rv ctx 

The CharParser instance is self-explanatory: 
instance (Alternative p, CharParser p) => 

CharParser (PaullT p) where 
token c = PaullT r 
where r PurePos — empty 

r (HeadPos kh ) = modHead kh $ token c 
r TailPos = token c 

Finally, the ApplicativeFix instance handles recursive references: 
instance (Alternative p, ApplicativeFix p) =£- 
ApplicativeFix (PaullT p) where 
afix (pf :: V q . Applicative q =>■ 

(PaullT p o q) a —► (PaullT p o q) a) = PaullT r 
where ... 

In a pure context, we just kill recursive occurrences: 

r PurePos = paullT (afixKill pf) PurePos 
In other contexts, we implement the transformation rule described 
above (taking into account the head modification in a head context). 
We use an o mitte d function many Comp: a version of manyAF 
from Section |5d| lifted to composed functor (p o q): 
r (HeadPos hm) = rNP hm 
r TailPos = rNP DontTouch 

rNP :: HeadMod —tpa 
rNP hm = afix $ A self —> 

foldr ($) ® rStart hm self © manyComp (rDeriv self) 

rStart and rDeriv play the role of bsHead' and bsTail' in our 
earlier explanation. We define rStart by calling the function pf 
with a recursive occurrence that behaves as empty in pure and head 
contexts, and as an actual recursive reference elsewhere: 
rStart:: Applicative q => HeadMod —»• (p o q) a —»• (p o q) a 
rStart hm self = 
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Comp $ flip paullT (HeadPos hm ) $ comp $ pf $ 
Comp $ PaullT $ Acte —¥ 
if cte = TailPos then comp self else empty 


Finally, as discussed in Section |3~4| rDeriv is a prime example for 
the need of the coapp function described. It produces a parser with 
result type a —>■ a to be used in the definition of rNP above. In ad¬ 
dition to the recursive occurrence self from the call to afix, coapp 
gives us a placeholder prev to substitute for left-recursive occur¬ 
rences. Using our RuleCtxs, we call / with a recursive reference 
behaving as prev in head positions and as self elsewhere: 
rDeriv :: Applicative q =>■ (p o q) a -*■ (p o q) (a -y a) 
rDeriv self = coapp $ rDeriv' self 
rDeriv' :: V q q2 . (Applicative q, Applicative q2) => 

(P ° q) a -A ((p o 9) o q2) a -A ((p o 5 )o q 2) a 
rDeriv' self prev = 
assocComp 2 $ Comp $ 
flip paullT (HeadPos KillHeads) $ comp $ 
pf $ Comp $ PaullT rself where 
rself :: RuleCtx -A p (q o q2) a 
rself PurePos = empty 

rself HeadPos { } = comp $ assocComp 1 prev 
rself TailPos = liftOuter (1) comp self 

With this machinery, the function transformPaull applies the left- 
recursion removal transformation to a parser: 

transformPaull:: Alternative q =>■ PaullT q a -A q a 
transformPaull p = paullT p PurePos 

® paullT p (HeadPos DontTouch) 
Omitting some uninteresting glue code to the standard Applicative 
parsing library uu-parsinglib, we can now apply its standard 
error-correcting parsing algorithm to our transformed and no longer 
left-recursive parser expr from Section [5~3l 
exprParse :: String -A Int 
exprParse = parseUU $ transformPaull expr 
testParse = exprParse "l+7*3+(8*l+2*6)" 

7. Related Work 

Applicative functors For background on applicative functors, we 
refer to McBride and Paterson (23). Note that their bracket notation 
(translating [ / ui... u„ ] to pure f ® ui ® ... © Un) is orthogonal 
to our alet syntax and would fit well in alet right-hand sides. 
Lindley et al. clarify the relation between Applicative functors, 
Arrows and Monads (20). Applicative parser combinators were 
popularised by Swierstra and colleagues mm, who have shown 
them better suited for analysis and optimisation. A better handling 
of recursion is still a missing piece of the puzzle, and has been a 
motivation for work on observable recursion (see below). 

HOAS representations There is a wide variety of research on 
HOAS representations and how to prevent the problem discussed 
in section [3] We have already discussed Carette et al. (5)’s finally 
tagless style, built on the work by Washburn and Weirich (35). Chli- 
pala has proposed Parametric HOAS, also exploiting parametricity 
in a better HOAS encoding (6). Contrary to Carette et al., this re¬ 
sults in an initial encoding instead of a final one. PHOAS has been 
used by Oliveira and Cook to obtain observable monomorphic re¬ 
cursion (25) in graph structures. In follow-up work developed in 


parallel with ours, Oliveira and Lbh extend this to typed DSLs 
with mutually recursive bindings, leading to a solution with many 
similarities to ours (26). In addition to observable recursion, they 
also provide observable sharing, which we have not considered. 
Their model of m utual ly recursive binders uses techniques similar 
to those in section [572] but they keep mutual bindings as primitive 
instead of reducing them to sequences of simple binders like us. For 
achieving a usable end-user syntax, they demonstrate the use of the 
impure data-reify library, while we propose the alet syntax. 

We have experimented with using an initial encoding based on 
PHOAS instead of our finally tagless encoding. This involves a 
version of our Rule data type parameterised by a type constructor v 
that represents variables of a certain type. We also add an additional 
Var constructor and a different recursion primitive Fix: 

data PRule v a where 
Var :: v a -A PRule v a 
Fix :: (v a -A PRule v a) -A PRule v a 
Seq :: PRule v (a -A b) -A PRule v a -A PRule v b 

type Rule a = V v ■ PRule v a 
Parametricity of bindings is enforced by requiring the terms to sup¬ 
port any variable type constructor v. However, this representation 
also suffers from the problem discussed in section |3T2| and does not 
permit the definition of an analogon of coapp. As in section [3~4) 
this can be solved by changing Fix’s type to the rank-2 type 

Fix :: (V w. Applicative w =>■ 
v :<: w —> w a —> PRule w a) —t PRule v a 

v :<: w is a synonym for V a ■ v a —► w a, i.e. an embedding of 
variables v a into a wider set w a. We have not found reasons to 
prefer this encoding over ours, although some people may prefer an 
initial encoding over a final one. This encoding may translate better 
to predicative languages like Agda. 

Observable recursion through fixpoint primitives We have al¬ 
ready seen Erkok and Launchbury’s MonadFix type class and fix- 
point primitive mfix, typed MonadFix m =$■ (a -A m a) -A 
m a dH. They focus on value recursion; mfix’s type and 
its axioms (see Section |4,2) are not suited for effectful recursion. 
Erkok and Launchbury extend Haskell’s do-notation with recursive 
value bindings that are desugared into applications of mfix. 

Hughes proposed the use of Arrows in functional languages (3D 
as a generalisation of monads, similar to applicative functors. In a 
paper proposing a do-notation for arrows, Paterson also proposed 
ArrowLoop: a type class modelling value recursion in arrows (27). 
Similar to MonadFix, the ArrowLoop axioms prescribe a value- 
recursion semantics and do not allow effectful recursion. 

Observable recursion through typed references Both Baars and 
Swierstra HGD and Devriese and Piessens mamma each define 
observably recursive encodings of grammars based on a well-typed 
representation of references. Baars and Swierstra employ a form of 
de Bruijn-indices into a type-level encoding of a type environment 
and Devriese and Piessens require the user to define an encoding 
of the grammar’s non-terminals at both type and value level. Baars 
and Swierstra implement a fixpoint primitive and propose a general 
form of syntax macros for Haskell to recover a nice syntax for their 
grammar definitions. Brink et al. (4) demonstrate a deeper encoding 
of parsers than ours, representing grammars as a set of production 
rules parameterised by a set of non-terminals in the dependently- 
typed language Agda. Compared to these approaches, our fixpoint 
primitive is more powerful. For example, we support higher order 
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recursive operators like manyAF from Section |5. 1 1 without hard¬ 
coded support in the parsing library. 

Dependently typed recursion In an unpublished draft, Danielsson 
and Norell (9) show how left-recursive parsers can be excluded in a 
dependently typed parser combinator DSL. They restrict the recur¬ 
sion in the DSL while we support other interpretations of the recur¬ 
sion that is there. Danielsson |7j uses mixed induction-coinduction 
to define parser combinators that support left-recursion, but (im¬ 
pressively) remain provably total and correct. Danielsson’s tech¬ 
nique does not seem to allow the choice of non-standard fixpoints 
in the same way as we do. For the following parser test 
test : CoN —J P false 
test zero = sat (= ’a’) 
test (sue n) = j) test2 (b n) • U ? (sat (= ’b’)) 
we suspect test oo is indistinguishable from finite test n making 
first set calculation and other algorithms hopeless. 


8. Conclusion 

We have shown that effectful recursion is an important prob¬ 
lem in several domains. We propose the class ApplicativeFix of 
Applicative functors with a recursion primitive afix. It uses a fi¬ 
nally tagless HOAS encoding of a recursive binder /a adapted to 
Applicative functors with a rank-2 type that allows to exploit the 
Applicative values-effects separation. We use generic program¬ 
ming techniques to derive mutual recursion primitives and propose 
the alet construct as a shallow form of syntactic sugar for afix 
with an implementation in GHC. We show that our approach is 
useful for (at least) two domains: parsing and functional reactive 
programming. Our approach supports higher-order operators like 
manyAF without ad hoc support in the DSL encoding. 
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